Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: instead of --part.userParticleHandler='', reduce part.minimalKineticEnergy #40

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

c-dilks
Copy link
Member

@c-dilks c-dilks commented Sep 15, 2022

So far we run npsim with --part.userParticleHandler='', which we thought we needed in order to see optical photons in the truth output. Today I learned we don't see them because the default part.minimalKineticEnergy is 1 MeV, too high for photons. Instead, we set this minimal energy to zero, and check if IRT reconstruction still works.

Relevant parts from DD4hep ParticleHandler.py

  def __init__(self):
    """Defaults"""
    self._minimalKineticEnergy = 1 * MeV
    self._userParticleHandler = "Geant4TCUserParticleHandler"

  def minimalKineticEnergy(self):
    """MinimalKineticEnergy to store particles created in the tracking region"""

  def userParticleHandler(self):
    """Optionally enable an extended Particle Handler"""

…KineticEnergy`

So far we run `npsim` with `--part.userParticleHandler=''`, which we
thought we needed in order to see optical photons in the truth output.
Today I learned we don't see them because the default `part.minimalKineticEnergy`
is 1 MeV, too high for photons. Instead, we set this minimal energy to
zero, and check if IRT reconstruction still works.
@c-dilks
Copy link
Member Author

c-dilks commented Sep 15, 2022

On second thought, after reading DDG4/plugins/Geant4TCUserParticleHandler.cpp, I don't think we should be using the default userParticleHandler (which is this Geant4TCUserParticleHandler), at least for how we are currently using the IRT code. In EPIC we have:

npdet_info dump $DETECTOR_PATH/$DETECTOR.xml | grep -E '^tracker_region'
tracker_region_rmax            =       83.500 = EcalBarrel_rmin
tracker_region_zmax            =      187.470 = EcalEndcapN_zmin

but the dRICH is outside of this; most likely the opticalphotons are thrown away by Geant4TCUserParticleHandler because they are not from within this tracker region.

@wdconinc do you have any suggestions how we should be running? Should we just continue to run npsim with --part.userParticleHandler=''?

@wdconinc
Copy link
Contributor

I have no opinion on the matter :-) As I think was clear from the tutorial :-\ I have a pretty poor grasp of what exactly causes MCParticle entries beyond the event generator input :-D

As a matter of default settings in npsim, we should try to limit how much non-event generator truth we write to the MCParticles branch, both to keep the default content of MCParticles dominated by the event generator record that most people expect to find there, and to keep the size reasonable (we could easily store 1000s of MCParticles as truth, which would start to meaningfully impact our file size).

I hope that's not too vague ;-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants